TELEMATICS-BASED 
VEHICLE DATA ACQUISITION ARCHITECTURE 



FIELD OF THE INVENTION 

5 The invention relates generally to vehicle data acquisition equipment, and 

more particularly a vehicle data acquisition architecture for telematics-based vehicle 
applications. 

BACKGROUND 

1 0 Modern vehicles increasingly employ advanced electronic systems for 

improved communications, safety, vehicle operation and control. Due to their 
complexity, appropriate methods for testing and diagnosing the systems after 
deployment in the vehicle is important. However, in order to diagnose one or more of 
the systems, appropriate vehicle data often needs to be extracted from the systems. 

15 Service bays typically carry out the diagnostics during standard warranty services 
and/or following a suspected system failure. 

Typically, a vehicle data bus infrastructure handles the signal communication 
to and from the system(s). Vehicle data bus architectures, and the data conveyed on 
the buses, are typically vehicle-dependent, or specific to the vehicle make and/or 

2 0 manufacturer. With exception to the legislative requirements (e.g. OBDII), 

conventional methods of interfacing with the vehicle data bus to effect diagnostics 
servicing often requires OEM-specific software and hardware. 

These differences in bus standards and bus data content give rise to an ever- 
increasing number of vehicle variants. This increasing number of variants presents a 

2 5 problem to the people who create telematics applications that use vehicle data to 

provide meaningful content. An example of such an application is Navigation that 
employs road-speed data to perform dead reckoning. 

Conventionally, application programmers often need an intimate 
understanding of each vehicle's data-bus architecture and associated knowledge in 

3 0 how to extract desired vehicle data from that architecture. This approach typically 

requires a substantial investment in time and cost for the programmer. In addition, the 
application generally requires customization from one vehicle make and/or model, to 
the next. This presents a problem in terms of application portability to all potential 
telematics platforms. 
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While the burdens and costs on the application programmer due to the 
conventional architecture described above present significant problems, the vehicle 
manufacturer also encounters undesirable issues. For example, in order to support the 
applications programmers conventionally, the vehicle manufacturer often must release 
5 sensitive intellectual property concerning the vehicle data-bus architecture. Moreover, 
the reliability of the vehicle electronics may be compromised through data access not 
controlled to the highest possible standards. 

What is needed and as yet unavailable is a telematics-based vehicle data 
acquisition architecture that enables telematics application programmers to develop 
1 0 applications that can extract vehicle data with generic data requests independent of the 
vehicle data bus architecture. The telematics-based vehicle data acquisition system 
described herein satisfies this need. 
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SUMMARY 

The telematics-based vehicle diagnostics system described herein provides a 
unique way to allow telematics application programmers to program their applications 
without the burden of knowing the precise data bus architecture for each vehicle make 
5 and model. This provides for better application portability, debug capabilities, and 
reduced overall development costs. 

To realize the foregoing advantages, the diagnostics system in one form 
comprises a method of acquiring vehicle data from a vehicle data bus. The method is 
responsive to the execution of a telematics application on a local telematics unit. The 

10 method comprises first accessing a local vehicle library, in response to vehicle data 
requests from the application. The local vehicle library then carries out steps 
comprising: retrieving vehicle data bus information from a database; using the vehicle 
data bus information to extract vehicle data from the vehicle data bus, the vehicle data 
corresponding to the requests for vehicle parameter data; interpreting the retrieved 

15 vehicle data; and providing the interpreted data to the telematics application to satisfy 
the request for vehicle data. 

In another form, a vehicle data acquisition system is described for extracting 
vehicle data from a vehicle data bus for telematics applications. The vehicle data 
acquisition system comprises a remote telematics unit having a server, and a vehicle 

2 0 database running on the server. The vehicle database includes vehicle-specific data 
bus architecture information. The system further includes a local telematics unit 
comprising a controller, an application program running on the controller and 
comprising at least one vehicle data request, and at least one library. The library is 
interposed between the application program and the vehicle data bus. Each library 

2 5 comprises a data retriever, a data interpreter, and a wireless link responsive to the data 

retriever for establishing a network connection to the remote server, the link providing 
a data download path for transferring the data bus architecture information to the local 
telematics unit. 

Other features and advantages will be apparent from the following detailed 

3 0 description when read in conjunction with the accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The vehicle diagnostics system and method will be better understood by 
reference to the following more detailed description and accompanying drawings in 
which 

5 FIG. 1 is a block diagram of a telematics-based vehicle diagnostics 

architecture; and 

FIG. 2 is a flowchart illustrating a method of acquiring data with the 
architecture of Figure 1. 
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DETAILED DESCRIPTION 

The telematics-based vehicle data acquisition architecture described herein, 
generally designated 10 (Figure 1), provides a unique way of simplifying the vehicle 
interface for telematics applications programmers. This is accomplished by 
5 interposing vehicle libraries 28 between the telematics application and the proprietary 
vehicle data bus (not shown). The vehicle libraries respond to generic requests from 
the application to access data from any vehicle data bus. As a result, the application 
programmer need not know the precise details of the vehicle data bus in order to 
develop the application. 

10 Referring now to Figure 1, the vehicle diagnostics architecture 10 includes a 

local data acquisition unit 12 having a telematics control unit (TCU) 14 installed in a 
vehicle 16. TCU's are well known, with one particular example known under the 
trademark "ONSTAR". Typically, the unit comprises a computer having hardware 18 
that connects to the vehicle internal data network (not shown), often referred to as a 

15 control area network, or CAN. One standard for a suitable network is known under 
the J1850 specification, although other standards may be employed as well. 
Applications such as navigation, security, and vehicle diagnostics are possible through 
the TCU's interface to the vehicle data bus infrastructure. 

Further referring to Figure 1, the local data acquisition unit 12 includes a 

2 0 collection of software modules to control and direct the hardware 18 to provide 

benefits for telematics applications programmers. Included in this collection are low- 
level drivers 20 in the form of software modules, a real time operating system 22 and 
software stacks 24. The operating system and software stacks provide a main control 
function over the TCU 14 and maintain tight cohesion between the TCU software and 

2 5 hardware 18. 

Sitting on the real time operating system 22 is a Java virtual machine (JVM) 
26 that provides an interpretation engine for Java-based telematics application 
programs. The JVM interfaces with a set of runtime libraries 28 in the form of an 
application programmers interface (API) that provides the software functionality to 

3 0 generate an abstract interface between the hardware and software applications. The 

libraries are constructed using Java technology and include the functionality to 
interface with the high-level applications program, retrieve data bus information, 
establish a wireless link, extract data from the vehicle data bus, and interpret the data 
as more fully described below. 
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User-generated Java-based algorithms, diagnostic sequences and the like sit on 
the libraries in the form of third-party applications 30 and services 32. These modules 
control how the libraries are used as information building blocks. As an optional 
feature, a human machine interface 34 such as a graphical user interface (GUI) is 
5 provided. 

The telematics unit 14 preferably employs an open-standard services delivery 
platform, such as that specified by the Open Services Gateway Initiative (OSGi). The 
platform provides a flexible delivery mechanism over wide area networks to local 
networks and devices. 

10 To take advantage of the telematics services delivery platform, the vehicle data 

acquisition architecture further includes a vehicle data center 40 based remotely from 
the local vehicle data acquisition unit 12. The center comprises a vehicle data server 
42 operating in cooperation with a vehicle database 24. The database provides a 
repository for vehicle-specific data bus information. The information is gathered from 

1 5 vehicle manufacturers and includes proprietary data bus configurations for each 
vehicle make and model potentially served by the telematics application. 

In practice, a telematics applications programmer can take advantage of the 
vehicle libraries 28 to simplify the application at a high level such that data requests 
may be made genetically, or independent of the vehicle make or model. As an 

2 0 example, and referring to Figure 2, if vehicle speed data is required during the 

execution of a telematics application, at step 200, the following lines would suffice to 
secure the data for the application: 

IF 

2 5 GetVehicleData(EngineSpeed) > 5 mph 

THEN 

CheckValue(DoorsLocked) 

Further referring to Figure 2, with the application running, the program string 

3 0 regarding engine speed initiates action, at step 202, on the part of the runtime library 

to furnish the vehicle speed data to the application. The vehicle runtime library 28 
then responds to the application request, at step 204, by retrieving the proprietary 
vehicle data bus information from the remote runtime database 44. The information 
includes, for example, the data protocol type, the access method for the parameter, 
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value addresses, shift and mask information, return value decoding methods, scaling 
and unit conversion, etc. 

The retrieval, at step 204, is accomplished by establishing a wireless link 
through the open-standard services delivery platform, to the remote server 42. The 
5 server then queries the database 44 for the appropriate vehicle data bus information, 
and downloads it to the TCU runtime library 28 via the wireless link. 

Once the proprietary vehicle data bus information is retrieved, the specific data 
(in this example, vehicle speed) is extracted from the databus, at step 206, in the form 
of raw bytes. The extraction includes passing the data bus information to a protocol 

1 0 driver (not shown), and retrieving the specific raw data from the protocol driver. The 
library 28 then utilizes the value decoding, scaling and unit conversion information to 
interpret the data, at step 208, and provide it in a meaningful format for use by the 
application, at step 210. The application then utilizes the information to provide its 
intended content. The information retrieval potentially occurs many times throughout 

15 the application execution, providing vehicle data bus access to the application via the 
runtime library. 

Those skilled in the art will recognize the many benefits and advantages 
afforded by the present invention. Of significant importance is the use of an 
intermediate abstract software layer to extract vehicle data requested by a telematics 
2 0 application. By employing the library, the burden of knowing the specific vehicle bus 
architecture is removed from the application programmer and undertaken by the 
library and the remote server. As a result, telematics applications that utilize vehicle 
data can be developed at higher levels, significantly improving the portability of the 
application between platforms. 

2 5 While the invention has been particularly shown and described with reference 

to the preferred embodiments thereof, it will be understood by those skilled in the art 
that various changes in form and detail may be made therein without departing from 
the spirit and scope of the invention. For instance, although the vehicle data 
acquisition architecture described herein identifies a specific diagnostics telematics 

3 0 use, it should be understood that any telematics application using vehicle data (such as 

navigation, security, etc.) may benefit from the architecture described herein. 
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